
REMARKS 

Introduction 

Claims 1-5 are currently pending in the present application, with 
claims 1 and 3-5 having been amended herein. No new matter is presented 
by the claim amendments. It is submitted that claims 1-5 are allowable in 
view of the foregoing amendments and following remarks. 

The Non-enablement rejection 

Claims 1-5 have been finally rejected under 35 U.S.C. §1 12, first 
paragraph, as being non-enabling. In this regard, the Examiner sets forth 
two separate grounds for lack of enablement. First, it is asserted that 
because claim 1 recites processor readable instructions that implement a 
network status reporting level determination mechanism, disclosure of the 
program code is required by the statute. Second, it is asserted that there is 
a "remaining question" as to whether the specification provides enough 
information for those skilled in the art to make and use the invention 
without undue experimentation (which question is answered "no" by the 
Examiner) . 

As to the first stated ground for lack of enablement, Applicant 
respectfully disagrees with the position taken by the Examiner that a listing 
of program source code is required for enabling the recited claims. In this 
regard, it is initially noted that the Court of Appeals for the Federal Circuit 
has concluded unequivocally that disclosure of a code listing is unnecessary 
when a programmer of reasonable skill could write a version of the program 
with reasonable effort. See Northern Telecom Inc. v. Datapoint Corp. , 908 F. 
2d 931, 934 (Fed. Cir. 1990). Since the burden of proof lies with the Patent 
Office in establishing a prima facie case, it is submitted that the mere 
statement by the Examiner that a program listing is required simply 
because the element "processor readable instructions" is recited in the claim 
fails to carry the burden of showing that a programmer of reasonable skill in 
the art would not be able to write a version of the processor readable 
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instructions so as to implement a network status reporting level 

determination mechanism. Since this secondary inquiry into the 

competence of a programmer of reasonable skill in the art is essentially 

analogous to the second stated ground for lack of enablement, it is 

submitted that in reality the first ground of rejection is spurious, and that 

there is only one legally permissible basis for the enablement rejection, 

namely, the asserted ground that the skilled practitioner would not be able 

to practice the invention based on the disclosure in the specification without 

undue experimentation. 

With regard to this asserted ground for lack of enablement, the Final 

Office Action indicates that: 

[T]he specification fails to disclose how to determine 
a level of detail to report the network status to [the] 
. network operations console based on at least one of 
[a] user request and a predetermined allocation of 
bandwidth for use in reporting network status 
wherein regardless of the user request, the level of 
detail is limited to a maximal level permitted by 
available bandwidth as claimed. Figure 2 merely 
shows several rectangular boxes labeled as daemon, 
manager, switches and consoles interconnected by 
lines. The description of Figure 2 in the 
specification does not provide any more information 
than what is already shown in Figure 2. A skilled 
programmer would not be able to transform the 
hardware connections shown in Figure 2 to 
instructions [that] when executed would control a 
processor to operate in a manner as claimed. 

In the previously-filed response to the first Office Action, it was 
noted that Figure 2 and the accompanying text of the present application 
explain the interrelationship among the various elements of the network 
system (i.e., the network operations consoles, the flow control daemon, the 
real time status manager, and the real time database daemon) such that one 
of ordinary skill in the art would be able to arrive at the claimed subject 
matter without undue experimentation. In particular, it was noted that 
the specification indicates that the flow control daemon acts as a filter for 
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network status information, gathering a range of information from the real 

time manager and database, but only providing the most essential 

information, or specifically requested information, to the network operation 

consoles so as not to exceed bandwidth limitations. 

Moreover, the specification provides further detailed description 

as to how the level of detail of reporting is determined. For example, the 

specification indicates that: 

[T]he number and sizes of messages that are 
allocated to network status information between a 
flow control daemon 15 and a network operations 
console 16A, 16B is a configurable quantity, that 
can be specified, for example in a configuration file 
resident on the workstation on which the flow 
control daemon resides. In other embodiments, the 
quantity is set via a local or remote (e.g., Web) 
graphical interface or by reading from a database. 
In yet another embodiment, the network operations 
console 16A, 16B transmits connection information 
to the flow control daemon 15 which aids in 
determining how much bandwidth on the 
connection LI to allocate to network status 
messages. (Specification, page 8, lines 26-32 
(emphasis added)). 

As further explained in the specification, the flow control daemon 
includes a network status reporting mechanism that "determines, based on 
available bandwidth and the number of check boxes 420 [configured at the 
user interface], the amount of information that should be reported back to 
the network operating tool user interface 22." (Specification, page 9, lines 1- 
3). The reporting mechanism can alter the level of reporting according to 
bandwidth requirements by providing "the highest level of detail that can be 
accommodated without exceeding the bandwidth allocated to network status 
information for the particular consoles 16A, 16B." (Id. , lines 9-12). As also 
explained in the specification, "the system limits the number of ports whose 
statuses can be displayed . . . such that the bandwidth of the link LI 
between the flow control daemon 15 and the console 16 is not exceeded. 
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The system can then devote the remaining bandwidth not used . . . for 
additional summary information." (Id. , lines 16-19). 

These sections of the specification clearly explain how the level of 
detail reported is determined by: i) user configuration, which determines 
such information as the particular switches for which information is desired; 
and also by ii) bandwidth preservation logic at the flow control daemon 
which automatically modifies the reported level to higher levels of 
abstraction, i.e., lesser degrees of detail, where bandwidth resources are 
scarce. Figures 17 to 19 illustrate examples of varying, hierarchical degrees 
of report detail (medium, high and low levels, respectively). In Figure 17, 
summary information is provided for every port of each network switch in 
the span being monitored. In Figure 18, detailed information is provided for 
each of the ports, and in Figure 19, for a number of switches, no port 
information is provided, but only summary information about the switch as 
a whole (e.g., for switches 1 and 4). 

In view of the above-noted descriptions found in the specification, it is 
submitted that programmers of skill in the art could program, without 
undue experimentation, user interface configuration functionality (for 
example, using Visual Basic in a Windows-based operating system 
environment) for setting user- requested levels of report detail that operate in 
concert with fail-safe algorithms residing at the flow control daemon which 
override or modify user-requested levels to accommodate bandwidth 
requirements. 

The Examiner has made conclusory assertions, but the Examiner has 
offered no concrete evidence that undue experimentation would be required 
to achieve the claimed invention. Furthermore, Applicant notes that the 
relevant factors to be considered in determining whether a specification 
satisfies the enablement requirement include, but are not limited to, the 
following: the breadth of the claims; the nature of the invention; the state of 
the prior art; the level of ordinary skill; the level of predictability in the art; 
the amount of direction provided by the inventor; the existence of working 
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examples; and the quantity of experimentation needed to make or use the 
invention based on the disclosure. (See M.P.E.P. § 2164.01 (citing In re 
Wands , 858 F.2d at 737, 8 U.S.P.Q.2d at 1404 and 1407)). In this regard, 
the Federal Circuit has stated that it is "improper to conclude that a 
disclosure is not enabling based on an analysis of only one of the above 
factors," and that the examiner's analysis must therefore "consider all the 
evidence related to each of these factors" so that any nonenablement 
conclusion "must be based on the evidence as a whole." (See MPEP § 
2164.01). It is respectfully submitted that the Examiner has not addressed 
these required factors in a substantive manner. 

In summary, for the foregoing reasons, it is respectfully submitted 
that a prima facie case of non-enablement has not been established with 
respect to claim 1-5. In view of the foregoing, withdrawal of the rejection of 
claims 1-5 under the enablement clause of §112, first paragraph, is 
respectfully requested. 

Obviousness Rejection 

Claims 1-5 have been finally rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Pendleton, U.S. Patent No. 5,982,753, in view of Kavner, 
U.S. Patent No. 6,430,607. 

Initially, Applicant disagrees with the Examiner's statement made in 
the Final Office Action that "Applicants agree on the Examiner's 
interpretation of the Pendleton reference." Applicant does not admit, and 
has not admitted, to any "agreement" regarding interpretation of the 
Pendleton reference. 

Independent claims 1, 3, 4 and 5 recite determining a level of detail or 
reporting level to report said network status to said network operations 
console based on a user request and a predetermined allocation of 
bandwidth for use in reporting network status. 

It was previously acknowledged by the Examiner in the first Office 
Action that Pendleton does not disclose determining a reporting level to 



report said network status based on a predetermined allocation of 
bandwidth for use in reporting network status. 

In the Final Office Action, the Examiner asserts that the Kavner 
reference discloses "pre-allocation of sufficient bandwidth for transmitting 
message stream [wherein] the pre-allocated bandwidth limits the level of 
details." Without passing judgment as to the accuracy of this statement by 
the Examiner, it is noted that allocation of different bandwidths for data 
transmission for differing data services (such as MAIL, CHAT and VIDEO 
services) does not entail making a determination as to the level of detail of 
reporting information for a given service based on bandwidth considerations. 

As noted in the Applicant's previous response, while the Kavner 
patent refers to bandwidth allocations for client/ server or client/ gateway 
interactions, these allocations have nothing to do with changing a reporting 
level of a report on network status based on a predetermined allocation of 
bandwidth, as recited in the claims. In Kavner, a client processor includes 
an "MCP" (Microsoft Network Procedure Call) layer that uses a service 
priority table to allocate segment lengths to different segments for various 
on-line services, e.g., CHAT, MAIL, VIDEO GAMES, etc. (Kavner, col. 46, line 
17 to col. 47, line 19). Similarly, Kavner discloses making different 
bandwidth allocations to client-to-Gateway communication versus Gateway- 
to-client communication. While these bandwidth allocation schemes 
allocate different data for the respective services, no decision as to a level of 
detail of a report is made. In other words, Kavner does not disclose varying 
the amount of information gathered and displayed in a report based on 
bandwidth requirements and user request. In plain terms, neither 
Pendleton nor Kavner discloses or suggests the following decision making 
process: "X status information and Y bandwidth are provided. Although it 
would be most helpful to provide the total X status information, in view of 
the fact that there is only Y bandwidth available, it is determined to provide 
a Z level of detail with regard to the X information, which level of detail 
provides a certain percentage of X information." 
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In light of the above, it is submitted that the combination of Pendleton 
and Kavner, whether taken individually or in combination, fails to disclose 
or suggest determining a level of detail to report said network status to a 
network operations console based on a user request and a predetermined 
allocation of bandwidth for use in reporting network status, as recited in 
independent claims 1, 3, 4 and 5. Withdrawal of the final rejection of claims 
1-5 under 35 U.S.C. §103 (a) is therefore respectfully requested. 

CONCLUSION 

Applicant respectfully submits that the present invention is 
new, non-obvious, and useful. Reconsideration and allowance of pending 
claims 1-5 is respectfully requested. 



Respectfully submitted, 
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